fix: stop mail loops from bounces and autoresponders - #3628

What

Inbound mail is only screened with the X-Auto-Generated header, which nothing but helpdesk's own acknowledgement emails set. Real bounces and out-of-office replies pass straight through into ticket creation, where they can start a mail loop with the sending MTA.

Once a machine-generated mail becomes a ticket or a communication, three separate paths can reply to it:

1. New ticket ack — HD Ticket.after_insert sends the acknowledgement to raised_by, i.e. the address that just bounced.
2. Portal ticket threading — when the mail threads onto a ticket created from the portal, frappe CCs the parent doc's owner (mail_cc) on every inbound mail — the same dead address.
3. enable_auto_reply — an account with auto-reply on answers mailer-daemon directly.

Each reply bounces again, which creates another inbound mail, and so on.

Changes

All in helpdesk/overrides/email_account.py:

auto_generated_reason(msg) identifies machine-generated mail by the standard markers instead of relying on our own header. Checked in this order:

Why auto-replied passes: an out-of-office should reach agents on the ticket, and it cannot sustain a loop the way a bounce can — it only threads (no new ticket, so no acknowledgement goes out), and auto-responders rate-limit themselves to one reply per sender. Bounces and auto-generated feeds have no such limit, which is why they stay parked.

The bounce markers are checked before Auto-Submitted, so a DSN that also carries Auto-Submitted: auto-replied (Gmail's do) is still parked, with the recorded reason naming the dead address rather than a mere autoresponder.

Parked, not dropped. Matches go to handle_bad_emails(uid, message, reason) and land in Unhandled Email with the reason recorded, instead of being silently dropped by a bare continue. The framework version of handle_bad_emails only records for IMAP accounts, so it is overridden without the use_imap gate — POP3 and Frappe Mail drops leave the same trace, and a misclassified customer mail is always recoverable.

Agents still see what happened. Parking means bounces no longer thread onto tickets — an agent would never learn their reply went nowhere. When a parked mail belongs to an existing ticket (same In-Reply-To/References lookup the threading code uses), notify_ticket_of_parked_mail leaves an internal comment there by Administrator:

• bounce → "Delivery failed: the reply to this ticket could not be delivered to dead@example.com." (address taken from the DSN's Final-Recipient when present)
• parked auto-generated reply → "Auto-reply received from postmaster@example.com."

Comments notify nobody (no @mention), customers never see them, and a comment failure only logs — it cannot break the mail pull. No dedupe: one comment per parked mail, naturally capped at one per reply an agent sends.

Deliberate behavior notes:

• Machine-generated mail other than auto-replied is parked, including Auto-Submitted: auto-generated alert mail (monitoring systems, cron jobs). Any auto-generated sender is one sloppy autoresponder away from a loop with our acknowledgement, and a misfiring monitor floods the drawer instead of the ticket queue. If alert-to-ticket is ever needed, it should be an explicit account setting in a follow-up.
• A threaded auto-reply is a customer communication, so it can flip a Replied/Resolved ticket's status back — the pre-existing behavior for any customer reply.

Testing

helpdesk/overrides/test_email_account.py — 15 tests:

• 11 pure stdlib unit tests over auto_generated_reason and _failed_recipient with real message fixtures (Gmail DSN with a message/delivery-status part, out-of-office kept, quarantine alert parked, a DSN with no Return-Path, genuine customer replies, the Auto-Submitted: no cases).
• 4 integration tests (skipped automatically outside a site): the non-IMAP Unhandled Email trace, and the ticket comment for a matched bounce, a matched auto-generated reply, and an unmatched bounce (no comment).

Also verified end to end on a dev site by driving get_inbound_mails with a stubbed mail client: the bounce is parked with reason delivery status notification and the ticket gets the delivery-failed comment with the failed address; the genuine customer reply in the same batch is kept.

Screenshots

The agent's reply bounces and the customer's out-of-office arrives, on the same ticket. The bounce is parked and leaves the internal comment; the out-of-office threads like a normal reply. Before this PR the bounce would have threaded in as a fake customer reply and started the loop; agents saw nothing about the failed delivery.